Skip to content

Ignore exception on cancel/fail race in CancellableContinuation #896

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 18, 2018

Conversation

elizarov
Copy link
Contributor

There seems to be no other way to satisfactory fix the problem of a race between cancellation on CancellationContinuation and concurrent failure of the corresponding background process in a way the distinguishes "failure from cancellation attempt" from a "true failure" without placing undue burden on anyone who is implementing await() extension function for various future types.

  • Added testTimeoutCancellationFailRace that works as a perfect litmus test; being allowed to run for a while it realiable detects various problems in alternative approaches.
  • Optimized CancellableContinuationImpl; merged its code with AbstractContinuation class that is not needed as a separate class and it removed.
  • Deprecated and hidden CancellableContinuation.initCancellability(); it is now always invoked after the end of the block that was passed to suspendCancellableCoroutine.
  • Deprecated holdCancellability parameter to an internal suspendAtomicCancellableCoroutine function.

Fixes #892
Fixes #830

@elizarov elizarov requested a review from qwwdfsad December 16, 2018 13:27
elizarov added a commit that referenced this pull request Dec 16, 2018
This is part of the problem that is show in issue #893. The other
part of the problem (what happens during race) is addressed by PR #896

Fixes #893
elizarov added a commit that referenced this pull request Dec 17, 2018
This is part of the problem that is shown in issue #893. The other
part of the problem (what happens during race) is addressed by PR #896

Fixes #893
elizarov added a commit that referenced this pull request Dec 17, 2018
This is part of the problem that is shown in issue #893. The other
part of the problem (what happens during race) is addressed by PR #896

Fixes #893
There seems to be no other way to satisfactory fix the problem of
a race between cancellation on CancellationContinuation and
concurrent failure of the corresponding background process in a
way the distinguishes "failure from cancellation attempt" from
a "true failure" without placing undue burden on anyone who is
implementing `await()` extension function for various future types.

- Added testTimeoutCancellationFailRace that works as a perfect litmus
  test; being allowed to run for a while it reliably detects various
  problems in alternative approaches.
- Optimized CancellableContinuationImpl; merged its code with
  AbstractContinuation class that is not needed as a separate
  class and removed.
- Deprecated and hidden CancellableContinuation.initCancellability();
  it is now always invoked after the end of the block that was
  passed to suspendCancellableCoroutine.
- Deprecated `holdCancellability` parameter to an internal
  suspendAtomicCancellableCoroutine function.

Fixes #892
Fixes #830
@elizarov
Copy link
Contributor Author

All review issues were addressed.

@qwwdfsad qwwdfsad merged commit 876e9ba into develop Dec 18, 2018
@qwwdfsad qwwdfsad deleted the cancel-fail-race branch December 18, 2018 09:08
@gildor
Copy link
Contributor

gildor commented Dec 18, 2018

Are there any estimates about release date with this fix?

@qwwdfsad
Copy link
Collaborator

@gildor 1.1.0-alpha today or tomorrow and 1.1.0 on Friday if everything goes well

@gildor
Copy link
Contributor

gildor commented Dec 18, 2018

@qwwdfsad Great news, just in time, I just didn't want to release kotlin-coroutines-retrofit with workaround that uses internal API.
Now I will just recommend all users to update coroutines to 1.1.0 and change nothing with my adapter
Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants